Conversation
|
Hmm, seems like the style checker isn't happy with mixing |
|
Since #4433 seems close to merging, I can rebase on top of it once merged. |
8b32bb3 to
e91f182
Compare
|
Rebased on top of the GNU changes :) |
|
Thanks! Sorry it's taken me a while, I'll try to look at this very soon |
tgross35
left a comment
There was a problem hiding this comment.
Thanks for working on this! Left a few comments here.
For the style check, are the changes it is suggesting possible? If not, that will probably have to be updated unfortunately (hopefully we will be able to reorganize things at some point so it's less annoying...)
|
Thanks for the review! I'll get around to implementing the changes hopefully in the next few days. I'll try figure out how to pass the style lints - but it might need a new file. After this merges and when 1.0 is closer to release feel free to ping me on GitHub and I can help fully complete the transition for these changes in the 1.0 branch on the musl side :). |
9b5ca40 to
f669296
Compare
|
Thank you both! For people following from the sidelines like me, could someone confirm what this means in practice -- is the plan to backport part of this to 0.2, or will users have to wait until the 1.0 release? (The tracking issue still has quite a few points but I'm not clear how up to date it is...) Sorry for taking your time on paperwork, I'd just like to get an idea on when users will be able to use this (I'd probably need to prepare a separate rust build for our older arm32 systems if this still more than a couple of years away) |
|
The plan is for 0.2 indeed, I’ll backport it soon then it will be usable under the unstable env. Eventually I’d like to come up with a more stable way to control this (probably a cfg you can set via RUSTFLAGS), which will also make it to 0.2 and replace the env. Same story for glibc. When we actually have the 1.0 release we’ll drop the cfg and default to 64-bit time_t on all platforms. Until then, testing is very much appreciated :) |
|
Great, thanks for confirming! I did a build with this branch back in June and it worked fine (at least I didn't notice any weird behavior, and my server didn't break when manually setting the date past 2038), but I'll definitely make time to retest at various parts of the process (soonish on master as a couple of things changed since, and when it gets backported etc), feel free to ping me if you want testing on later PRs and you remember (no harm either way). |
(backport <rust-lang#4463>) (cherry picked from commit de1bd4e)
The structures are the same - and this follows the upstream definition On musl at least, blkcnt64_t == blkcnt_t == i64 and ino_t == ino64_t == u64 (backport <rust-lang#4463>) (cherry picked from commit 9ca4ae9)
This feature is enabled with independently from musl_v1_2_3 to support time64. Defining this feature makes this roughly equivalent to upstream commit bminor/musl@f12bd8e. (backport <rust-lang#4463>) (cherry picked from commit 47960b4)
This is equivalent to upstream commit bminor/musl@9b2921b. (backport <rust-lang#4463>) (cherry picked from commit fa7e710)
This corresponds to upstream commit bminor/musl@1febd21 (most symbols) and bminor/musl@22daaea (only dlsym) (backport <rust-lang#4463>) (cherry picked from commit 6fcc954)
A bunch of properties were removed upstream and set to reserved. This matches upstream commit bminor/musl@827aa8f and bminor/musl@2d69fcf (backport <rust-lang#4463>) (cherry picked from commit 72a590f)
(backport <rust-lang#4463>) (cherry picked from commit 80b82d8)
Change time_t type to i64 Change struct stat, msqid_ds and shmid_ds to reflect This commit follows upstream bminor/musl@3814333 and bminor/musl@d6dcfe4 It also implements a fix from bminor/musl@0fbd7d6 (backport <rust-lang#4463>) (cherry picked from commit 793fa97)
This is primarily based on a small part of bminor/musl@3814333. This also integrates bminor/musl@3c02bac, which update MSG_STAT, SEM_STAT, SEM_STAT_ANY. These are based on the value of IPC_STAT, however we can just use `cfg` as it is effectively the same. (backport <rust-lang#4463>) (cherry picked from commit 3d9801d)
This fixes test failures on musl. (backport <rust-lang#4463>) (cherry picked from commit 8195473)
Namely, this allows `target_endian` as well as adds a constant array where certain configs are explicitly allowed (e.g. musl32_time64). (backport <rust-lang#4463>) (cherry picked from commit 75fb1f0)
Unfortunately does not seem to handle cfg_if well (backport <rust-lang#4463>) (cherry picked from commit 587fd84)
This reverts commit 34e7583. (backport <rust-lang#4463>) (cherry picked from commit 092ccf2)
This reverts commit 72fe537. (backport <rust-lang#4463>) (cherry picked from commit 7726e8f)
(backport <rust-lang#4463>) (cherry picked from commit de1bd4e)
The structures are the same - and this follows the upstream definition On musl at least, blkcnt64_t == blkcnt_t == i64 and ino_t == ino64_t == u64 (backport <rust-lang#4463>) (cherry picked from commit 9ca4ae9)
This feature is enabled with independently from musl_v1_2_3 to support time64. Defining this feature makes this roughly equivalent to upstream commit bminor/musl@f12bd8e. (backport <rust-lang#4463>) (cherry picked from commit 47960b4)
This is equivalent to upstream commit bminor/musl@9b2921b. (backport <rust-lang#4463>) (cherry picked from commit fa7e710)
This corresponds to upstream commit bminor/musl@1febd21 (most symbols) and bminor/musl@22daaea (only dlsym) (backport <rust-lang#4463>) (cherry picked from commit 6fcc954)
Description
This change includes time64 support for applicable architectures (x86, arm, mips and powerpc). This is based on the previous PRs to this repo as well as the musl changelog from 1.1.24 -> 1.2. It can be enabled with the environment variable
RUST_LIBC_UNSTABLE_MUSL_TIME64only when musl_v1_2_3 is enabled and the architecture is supported.A lot of structures, especially ones with mixed endian became excessively complicated, so I used
cfg_ifto separate them. It looks like you can only nests! {}incfg_if! {}, but not vice versa.As a note, I'm considering removing
musl_not_time64, and just keeping the old logic of allowing deprecated for function definitions involvingtime_tas it introduces necessary complexity.When libc 1.0 is released, I believe the best path would be to remove the
musl_v1_2_3feature, making it unconditionally enabled, keepingmusl_time64which will expand to(musl && time64_arch).Tested through QEMU for all architectures.
Sources
Sources are located on each commit, in the form of upstream commits
Checklist
libc-test/semverhave been updated*LASTor*MAXareincluded (see rust-lang/libc#3131)
cd libc-test && cargo test --target mytarget);especially relevant for platforms that may not be checked in CI
@rustbot label +stable-nominated